Checklist before requesting a review

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.

Description

Adds creation and mod dates to most main item tables that were missing them.
While useful for historical tracking, my main reason for this change is for consistency and open up more possibilities for caching.

Most "caching" done by GLPI is just memoization to reduce duplicated work within the same request, or caching some computed data between requests. Maybe in the future GLPI could cache more, and tracking these dates would make it easier to implement cache invalidation. Obviously if file-based caching is used it will probably not be much faster than just fetching results from the DB, nor would it be very efficient in terms of storage, but if Redis is used then it could be depending on where the DB is hosted and the type of data.

This could be more immediately useful in client-side applications in cases where a table scan would be done or many results would be fetched and reused in many places.

For example, A SPA frontend fetches the list of Domain Types using Apollo Client (id, name, date_mod) and caches it as it is assumed to not change often and be a relatively short list of options. Then when a user opens another of these dropdowns or needs to otherwise display/use extra information about them, even on another "page" as long as they don't refresh (unless it is persisted somewhere besides in memory), it is populated from the cached data instead of going back to the GLPI server and then the DB.

One solution is to use the Apollo client fetch policy to "cache-and-network" which would immediately use the data from the cache AND make the request to the GLPI server to update the cache (which could then trigger a component update), but this doesn't make sense in every case.

Another use case is differential updates. Instead of a Kanban view refreshing the entire view, refetching project and task details from the database, only the items changed since the last update could be fetched.

Another case is support for the If-Modified-Since/If-Unmodified-Since HTTP headers for REST endpoints.

Other PRs would be needed for:

• Adding a guard, at least at the API level, to prevent setting foreign key fields to items that don't exist (anymore). This may technically be an issue in the web UI but unlikely unless the item was deleted between the time a form loads and is saved.
• Updating the API schemas to add these new fields